home *** CD-ROM | disk | FTP | other *** search
/ TPUG - Toronto PET Users Group / TPUG Users Group CD / TPUG Users Group CD.iso / AMIGA / AMICUS / AMICUS08.ADF / Text / Lattice3.03bugs < prev    next >
Text File  |  1986-04-02  |  4KB  |  96 lines

  1.  
  2. The following is list of bugs (not verified) forwarded from Compuserve:
  3.  
  4. To those who requested it, here is a list of known bugs in V3.03;
  5.  
  6. 1. fopen() in append mode truncates the file.
  7.  
  8. 2. array subscripting of the form
  9.  
  10.         arr[i].ptr = &arr[n+1]
  11.  
  12. makes lattice generate incorrect code that results in an addressing
  13. exception.
  14.  
  15. 3. expressions of the form
  16.  
  17.         val += (-8)
  18.  
  19. generates addq or subq instructions, but does not switch the
  20. sense of the operation as it should.
  21.  
  22. 4. strtol() is busted.
  23.  
  24. 5. pow() loses precision (13th or 14th decimal place.)
  25.  
  26. Information provided by John Miessien (which I probably just
  27. misspelled horribly, sorry about that)
  28. of Lattice.
  29.  
  30. sdb
  31.  
  32. in addition we have found the following bugs with v3.03
  33. 1.  Unsigned divide by a power of two shifts right by an amount
  34.     which is dependent on other things than the constant.
  35.     take a look a the generated code the problem is obvious.
  36.     basically what goes wrong is that a register is loaded with the
  37.     shift count as a long (32 bit) constant....real clever when the
  38.     number is for example 3.... and then to top it off, it it loaded
  39.     in the top of the register   0x0003nnnn  where nnnn is garbage
  40.     then the "correct" shift is generated.   all this when there
  41.     is a shift constant amount instruction.    ah well.....
  42.  
  43. 2.  unsigned short times unsigned short >> 16 will always return 0
  44.     compiler seems to suddenly forget that multiply generates a 32
  45.     bit answer and shifts the word part of the register right 16
  46.     places
  47.                        -Metadigm
  48. Doesn't >> have higher precedence the * than *?   That would mean shift a 16bit
  49. int right (leaving 0), then multiply.
  50.  
  51.    Just a bit of information -- for all of your complaining about
  52. the Lattice compiler, and drooling over the Aztec compiler.
  53.  
  54.    It is possible to compile Lattice source and end up with 
  55. objects smaller than those created with the Aztec compiler. There
  56. is still no contest in speed, the Aztec is faster in all cases.
  57.  
  58.    The trick to with Lattice is to avoid using Lattice standard
  59. routines as found in chapter three of the Lattice C manual. Most 
  60. applications can get away with using the EXEC functions, or Intuition
  61. functions for IO, and not need the Lattice (portable) functions. 
  62. Amiga.lib even contains various incarnations of the Lattice function
  63. calls (but they are not complete and full functioned, printf for example).
  64.  
  65.   I have recompiled a number of programs and examples (from rkm)
  66. using Astartup.obj and just Amiga.lib. The code ends up on the order
  67. of 2-4k bytes, not 8-16k bytes. This is a significant reduction!
  68.  
  69.   There is no hard and fast rule for knowing if and when you can
  70. get around it. For small programs, you can just compile and link
  71. yourself to see if there are any undefined functions. Simple functions
  72. could even be handcoded and added to your libraries (for future references).
  73.  
  74.   Specifically, the program whereis.c (mailbox AmigaDos) now uses only
  75. 2.5k bytes of memory. It seems that the penalty is incurred when using
  76. LC.lib, which calls many varied routines for Lattice support.
  77. This is especially true of printf(), which by itself calls a number
  78. of routines. 
  79.  
  80.   If your useage of printf is limited to simple outputs, e.g. printing
  81. error messages, and numbers, and don't require alot of fancy formatting
  82. , or don't perform math within the printf arguments, you can probably
  83. use the version of printf() found in Amiga.lib.
  84.  
  85.   Also, a quick way to chop 3kbytes from your code is to compile your
  86. programs with the option '-v' set during pass 2 (LC2). This eliminates
  87. the stack checking code.
  88.  
  89. Try it -- and let me know what you think , and whatever else you 
  90. can find out.
  91.  
  92. Thanks.
  93.  
  94. Randy Weiner <<rweiner>> Commodore Technical Support
  95.  
  96.